Hello guys, past week has prepared some ups and downs for us. On the up side, we have marked the 0.10.12 as stable and we also moved closer to getting the multiplayer reasonably working. On the down side our reservation for the new office has been cancelled which means we had to start looking for an office place yet again. That is rather unfortunate because we really liked the place we picked originally. Anyway, I am sure we will find another one soonish (we have already had couple of viewings this week but so far without success).
Status report (Twinsen) On Monday June 18th, we marked the last version of 0.16 as stable. There were no major problems, so now we are almost exclusively working on 0.17. Work on 0.17 is progressing well: Regarding the new campaign, we are already internally playing a rough version of the new player experience. We are still trying to figure out the exact and final style and concepts for the improved GUI, but we have some GUI windows implemented in game already, plus many base widgets. We use those to get a feel of what works and what doesn't. The new graphics back-end rewrite is nearing finalization. A closed-beta branch was sent to a few players to test that rendering works correctly across different hardware. The rendering is faster and no major issues were reported so far. But there is still much to do, such as improvements to VRAM usage and many experiments with shaders. Since from the graphics department Albert is working on the GUI and V453000 is working on the new campaign, only Ernestas is left working exclusively on the entity graphics. He is reworking some more entities for high-resolution, so expect some teasers in the future. There are of course other small projects that are ongoing, such as improved pipe-fluid physics and improved map generation, but more on those when they are fleshed out. Oh, and our coding always goes as planned without any problems.
Hi folks, so this has been one of those weeks when it is suddenly Friday afternoon and you are wondering where did the week go. Fortunately there are the Friday Facts to put myself together and retrace the events=)) The Grey Zone At the moment we are kind of in a grey zone. The 0.12 bugs are more or less solved (though there is still some "popping up" of new issues) and the full speed work on 0.13 hasn't started yet (actually not even slow speed work has started). We are finishing with little (often technical debt) tasks from our internal lists. There is just ton of issues like: fixing locale fonts, updating tips and tricks, writing tests for compilcated existing functionality, tweaking our automatic deployment and testing setup, auto-generating the Lua API documentation, fixing sound glitches, etc. The list goes on. One of the tasks has been related to our headless binary. This is the binary to run on linux servers without graphics card. This is now available in the downloads section alongside other releases. There is a small convenience difference where by clicking the download, the resulting download link (from one of our cdn servers) is valid for 10 minutes (instead of regular 10 seconds) so the server owner can conveniently copy this url and download the game directly from the server. In the future we plan to have the updater work for headless servers as well so that will make things even more convenient. The good news is that the list of these little tasks is getting shorter. Also we have already more or less agreed on distribution of big tasks for the 0.13. These have been discussed in the past and are also visible at our roadmap. Some work on these should start already next week. We will keep you up to date=)
Bugfixing report (posila) Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems. We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS. Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17. I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what. One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.
This week's Friday Facts is brought to you by Robert aka Twinsen aka that Romanian dude aka the Combinator guy. I'll be talking about the improvements that have been done so far in 0.13 to the circuit network.
Tomorrow's party Since a couple of weeks ago I was working for the 1M Party. Made some little graphic design jobs which finally became not that little and much more than "some little". I have to admit that I had quite some fun doing them, cause these small things are giving me the chance to experiment and play with the graphical identity of Factorio, like the happy logo variation, the small jumping gear, some layouts, the 1 color version of the Factorio logo and so on. Luckily I finished the jobs with time enough as to come back to the game gfx. But to be honest, Jitka is the person who's really taking care of every single detail for the party, and preparing and organizing everything. She became a master with the stamp and other stuff that I can't reveal just to not spoil surprises.
Offshore pump redesign V453000, Albert As one of the last entities which do not have high resolution graphics, the time has come for the offshore pump. The offshore pump is practically a 1-tile entity, but they must have a 1 tile gap between each other. It is also the only entity placed on a water tile at the moment. When we changed the way how terrain to water transitions work, we moved the offshore pump to be placed on the water tile. This can result in the pump drawing over terrain in ugly ways. With the redesign, we took the oppourtunity to move the offshore back onto land, and additionally the pump checks a 2x3 tile water area in order to be buildable. The new placement rules only applies to newly built pumps. Offshore pumps on existing maps will keep functioning, they’ll just be shifted out from the shore. There is no blue colour for water integration at the tip of the offshore pump, so the offshore pump will look correct even with unexpected water types (not a big problem in vanilla). The water integration is split to an underwater layer which does not show when the pump gets landfilled over. In the basic concept, the offshore pump is another type of a pump, so it should be similar to the other pump entity Albert made a few years ago, including the animation and visible fluid in it. The obvious difference is the connection to water. However we felt that is not different enough and needs more visual balance, so we added a pair of supportive legs. We are planning to release the new offshore pump graphics with the next release, likely next week.
Inserters are now smarter Twinsen A few days ago I was investigating a rather minor bug report related to "Rotational Asymmetry in Belt/Inserter interactions" (aka Inserter was not behaving identically when rotated). This was a classic case of floating point equality comparison. The Inserter would move it's arm and then it would pick up the item if the current arm orientation is equal to the desired arm orientation. Because of some chain of calculations related to rotation, some precision was lost and the equality check would fail for 1 tick, delaying the item pickup for 1 tick in some Inserter rotations. So I fixed that by finishing the inserter movement if it's close enough. Now the inserters should be a tiny bit faster in some rotations, plus all rotations should again be symmetrical and identical. While analyzing the code and Inserter behavior for that bug, I also noticed that inserters with stack bonus would do nothing for 1 tick after picking up an item from a belt. I changed it so inserters will start moving to a new target immediately after they pick up something. This also sped up the Stack Inserter by a tiny bit. Both the speedups were enough to fix another bug that was often regarded by the other devs as "not a bug": A Stack Inserter was not fast enough to pick up all the items placed on a belt by another Stack Inserter. Furthermore, because of different timings, the amount of items a Stack Inserter would pick up would depend on how far that Stack Inserter was from the item source: We released the change on Thursday. Something strange was quickly discovered after release... From Nefrums speedrun stream. As someone from Twitch chat noted "Inserters are so fast now, they even don't care about the side of belt". Remember that I fixed the rotation problem by finishing the Inserter movement if it's close enough. Well, what ended up happening was what now the Inserter would stop 0.0001 degrees short of perfectly vertical. That was of course closer to the other belt lane so the item would be dropped there. Previously it was always dropped perfectly vertical, and the lane decision algorithm would choose the right lane. The fix was easy and it's probably released by the time you are reading this. So with everything fixed, inserters are now more consistent, predictable and intuitive, things that I think are important for a precise game like Factorio. Some situation might end up being slightly slower or will consume a bit more electricity, but generally inserters are now faster.
